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BACKGROU^D 

Ihe  technology  of  developing  software  has  made  significant 
advances  in  the  past  several  years.  Some  supervisors,  however,  still 
treat  it  as  if  it  were  a  "black  art"  and  have  no  notion  of  how  much 
progress  is  being  made  in  the  development  of  computer  programs,  ihis 
Ccin  only  mean  that  the  software  effort  is  being  performed  by  archaic 
methods  and  without  the  proper  support  tools.  Ihis  report  defines  an 
"environment"  for  developing  software.  A  proper  "environment"  not 
only  aids  the  developer  of  the  software  but  also  helps  the  supervisor 
in  managing  the  development  and  supports  the  creation  of  maintainable 
computer  programs. 

Ihe  cost  of  developing  conputer  software  has  become  one  of  the 
major  expenditures  of  doing  business  today.  According  to  the 
Governm^t  Accounting  Office,  two-thirds  of  all  federal  spending 
is  for  software  and  related  services<l>.  Ihe  Department  of  Defense 
spent  $3  billion  for  software  in  1980<2>.  A  stucty  in  1979  showed  that 
NSWC  consumed  approximtely  610  staff-years  in  the  development  of 
computer  software  delivered  to  the  Navy  and  Marine  Corps;  this 
increased  to  640  staff-years  in  1980.  In  1981,  there  were  1800  "user 
numbers"  for  the  Center's  mainframe  computers.  Thus  one  can  see  that 
in  the  Federal  Government  and  at  the  Naval  Surface  Weapons  Center  the 
development  of  software  is  big  business. 

Studies  of  software  projects  have  shown  that  67%  of  the  life- 
cycle  cost  of  a  software  project  (i.e. ,  "cradle  to  the  grave")  is 
spent  on  maintenance  <1>,  Mainteiance  is  defined  as  correcting 
errors  and  adding  enhancements.  It  therefore  seems  that  major 
consideration  during  development  ^ould  be  given  those  things  that 
will  nake  maintaining  the  software  less  costly  and  time  consuming. 

This  is  the  philoso{4]y  \^ich  will  be  used  in  defining  the  requirements 
for  a  generalized  SOFTWAI^  EMGINEERIMG  ENVIRCNNENT  (SEE) . 

Software  engineering  encompasses  procedures,  practices,  and 
tools  which  support  the  development  of  computer  software.  These  ideas 
did  not  appear  to  anyone  in  a  flash  of  enli^tenment  as  a  completed 
package  with  the  title  "Software  Engineering"  printed  on  the  front  of 
it.  "Good"  progrcmroers  have  used  nany  of  these  ideas  for  years.  The 
author  can  recall  using  the  concept  of  "hierardial  decomposition"  back 
in  the  late  1950 's.  These  ideas  have  recently  been  put  together  in  a 
package  and  the  name  "software  etgineering"  has  beai  attached  to  them. 

The  software  engineering  enviroment  described  in  this  report  is 
an  ideal  system.  All  software  development  does  not  warrant  the  cost 
of  developing  a  system  of  this  magnitixie.  It  is  true,  however,  that 
we  have  always  greatly  underestimated  the  amount  of  effort  required  to 
develop  software  and  the  more  costly  the  system  the  more  important  a 
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complete  envlroment  becomes.  Ihe  more  disciplined  the  effort  becomes 
and  the  more  support  that  is  provided  by  autcmated  tools  the  greater 
the  cost  savings  over  the  life  of  the  software.  If  an  environment  is 
already  in  place  it  is  cost  effective  to  use  it  for  all  but  the 
smallest  developments.  Ihe  underlying  conc^ts  and  principles  of 
software  eigineering  should  be  applied  on  all  software  efforts  v4ietiier 
the  work  is  to  be  done  by  one  person  or  mai^. 

Ihe  ^stem  described  provides  support  for  all  phases  of  software 
development  from  conc^tion  of  a  ^stem  to  solve  a  problem  to  sipport 
of  the  software  vAiile  in  operation.  Since  different  projects  may  get 
to  the  Center  in  differ^t  phases  of  development,  the  environment  as 
described  may  not  apply  in  its  entirety  to  all  projects. 


DEFINITION 

When  the  term  SOFTWARE  ENGINEERING  was  first  used,  it  was 
intended  to  draw  attention  to  the  fact  that  the  development  of 
software  possessed  neither  the  theoretical  basis  nor  tiie  discipline  of 
engineering  fields.  Ihe  term  was  also  intmided  to  contrast  with  the 
term  "computer  science",  vhich  was  perceived  to  be  more  concerned  with 
defining  the  underlying  principles  of  the  application  of  computers  and 
software.  Software  engineering  is  concerned  with  the  actual 
development  of  software.  The  most  widely  accepted  definition  of 
software  engineering  is: 


The  establishment  and  use  of  sound  engineering 
principles  in  order  to  obtain,  economically,  software 
that  is  reliable  and  works  efficiently  on  real 
machines.  F.  L.  Bauer<3> 


Webster  defines  environmmit  as  "the  surrounding  conditions  or 
influences."  A  SOFTWARE  ENGINEERING  ENVIRCNHENT  (SEE)  is  therefore 
defined  as  the  set  of  all  the  tools  necessary  to  develop  computer 
software  using  the  principles  of  "software  migineering."  These  tools 
should  be  automated  (on  a  computer) ,  integrated  (the  output  of  each 
tool  in  a  format  compatible  with  the  input  of  each  of  its  logical 
successors) ,  and  user  friendly.  As  someone  once  put  it,  "a  software 
engineering  enviroment  is  a  computer-aided  design  system  for 
software. " 
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SCnWARE  DEVELCPfOn'  AND  MAINOINANCB  PROBLEMS 

Nary  of  the  problems  i^ith  software  have  been  attributed  to  poor 
management  practices  during  the  development  phases,  ihis  is  probably 
true;  however,  it  hcis  not  adways  been  the  fault  of  the  manager.  In 
the  past,  software  developm^t  has  been  a  very  individualized  effort: 
the  quality  of  the  product  depended  totally  on  the  ability  of  the 
person  doing  the  development,  ihe  individual  st^s  in  the  process 
were  so  interwoven  that  it  was  generally  iirpossibie  to  chart  the 
actual  progress.  Ihe  Reifications  were  usually  determined,  or  at 
least  extoisively  modified,  while  the  design  was  being  done,  ihe 
design  and  the  coding  were  often  done  at  the  same  time;  that  is  really 
to  say  that  there  was  no  design.  Ihe  coding  was  a  monolith  and  errors 
corrected  in  one  section  fouled  up  other  sections  of  the  code.  No  one 
^  therefore  had  any  idea  how  close  the  project  was  to  completion.  Ihe 
old  adage  of  90%  complete  for  90%  of  the  project  was  thought  to  be  a 
reality  because  the  programmer  himself  really  could  not  determine  how 
close  he  was  to  being  finished.  Ihe  documentation  usually  was  never 
started  until  all  of  the  other  work  was  finished  eind  at  that  point 
even  the  programmer  had  forgottei  how  he/she  had  inplemented  many  of 
the  functions.  It  is  iirpossibie  to  manage  such  a  task  and  the  fact 
that  some  software  projects  were  successful  was  only  due  to  the  fact 
that  good  pecple  were  doing  them  and  the  manager  was  lucky. 

Ihe  underlying  causes  of  poor  management  mentioned  above  are  the 
same  things  that  cause  softweure  to  be  very  difficult  and  costly  to 
maintain.  First,  coding  is  not  an  ea^  thing  to  understand  at  best. 
Ihe  fact  that  the  documentation  was  poor  meant  that  the  maintenance 
people  were  on  their  own  with  little  help.  Ihat  is  why  it  was  so 
inportant  to  have  the  developers  maintain  the  software.  Ihe  fact  that 
the  coding  constituted  a  monolith  with  interdependencies  stretching 
from  beginning  to  end  made  it  very  difficult  to  modify  the  code 
without  introducing  new  errors. 


SOFIWARE  ENGINEERING  PHILOSOPHY 

Ihe  philosophy  of  software  eigineering  is  to  ajply  good,  well- 
defined,  logical  procedures  (what  is  meant  by  aigineering  principles) 
to  the  development  of  software  and  to  create  documentation  along  with 
each  step  in  the  development.  A  part  of  those  procedures  creates  the 
code  as  modules  with  no  dependencies  outside  their  own  boundaries. 

Ihis  breaks  large  problems  into  a  series  of  smaller  cxies  that  can  be 
better  understood  and  managed.  All  documentation  is  produced  while 
the  concepts  are  fresh.  It  is  maintained  on  a  conputer  for  easy 
reference  and  updating  and  every  item  can  be  traced  through  all  levels 
of  documentation,  ri^t  down  to  the  code  and  test  results. 
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One  of  the  fundamaital  goals  of  software  engineering  is  to 
idoitify  and  eliminate  errors  as  early  in  the  life  cycle  as  possible. 
Figure  1  illustrates  %hy  this  is  inportant.  ^e  further  into  the 
developinait  of  the  software,  the  more  costly  it  is  to  ranove  an  error. 
Ihis  is  rather  obvious  since  the  further  along  in  the  development  the 
more  effort  has  been  expended  on  each  item  (eg.  design, 
implementaticxi,  test,  docunentation,  etc.). 
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FIGURE  1.  ERROR  CORRECTION  COSTS  <4> 
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GENERAL  REQUIREMENTS 

A  Software  Engineering  Environment  should  fully  integrate 
development  and  communication  tools.  It  should  have  tiie  following 
features: 

1.  A  single,  ooirpatible  storage  format  for  all  documents, 
prograns,  and  data  files,  so  they  can  form  a  fully 
integrated  data  base 

2.  Software  tools  vdiere  the  output  of  one  is  in  the  form 
of  ir?)ut  for  suoessive  tools 

3.  Facilities  for  reporting  and  supervision,  that  cLLlow 
quick  surveys  of  progress  on  schedules  and 
specifications  witiiout  special  efforts  by  supervisors 
or  programmers  to  generate  those  surv^s 

4.  All  reports  from  the  system  designed  for  readability 
and  understanding 

5.  Facilities  for  comiminication  among  programmers, 
including  both  electronic  mail  and  "voice  mail" 
(electronic  storage  and  forwarding  of  voice  messages) 

6.  Facilities  vAiidi  force  disciplined  software  development 
proceeding  directly  from  the  specification  and  planning 
documents 

7.  Means  of  updating  and  annotating  programs  without 
destroying  the  original,  so  that  a  history  of  how  the 
program  has  evolved  is  preserved 

8.  Provision  for  creating  pointers  that  connect  new 
documents  or  programs  to  existing  information 

9.  An  information-display  management  ^stem  with  which  a 
user  can  examine  and  cross-section  the  available 
information  base.  For  example,  the  user  will  be  able 
to  view  simultaneously  a  statem^t  in  assanbly 
language,  the  hi^- level  language  statement  that 
generated  it,  the  associated  portion  of  the  design,  and 
the  original  specification  of  its  function. 

10.  Documentation  for  publication,  derived 

strai^tforwardly  and  semi-autcmatically  from  the 
integrated  data  base.  Documentation  will  not  be  a 
separate  and  belated  activity. 


5 


NSWC  ro  82-465 


THE  SOFTWARE  LIFE-CYCLE 

The  stages  of  a  software  life-cycle  can  be  defined  as  follows; 
Concept  Development 
Requirements  Specification 
Software  System  Design 
Coding  and  Checkout 
Testing 
Integration 

Operational  Test  and  Evaluation 
Deployinent/Maintenance<5> . 


CCXJCEPT  DEVELOPMENT 

The  concepts  phase  consists  of  defining  the  problem  that  is  to  be 
solved.  The  priitary  need  in  this  phase  is  to  provide  clear,  concise 
documentation.  The  problems  and  subproblems  should  be  specified  in 
such  a  way  that  it  will  be  possible  to  trace  the  solution  throu^  each 
level  of  subsequent  documentation.  This  will  consist  of  a  computer- 
assisted  documentation  ^stem  vhich  allows  and  requires  unique 
identification  of  each  problem.  At  this  point  consideration  of 
whether  the  solution  will  be  totally  hardware,  totally  software  run  on 
a  genercd-purpose  computer,  or  a  computer  embedded  in  a  ^stem  with 
appropriate  software,  is  not  germane.  What  often  h^pens  is  that 
feasibility  studies  are  not  made  and  we  build  solutions  for  problems 
we  don't  understand  and  which  often  are  the  wrong  problems. 

The  approach  to  doing  analysis  must  be  as  disciplined  as  that  for 
doing  coding.  There  eure  several  methods  and  techniques  available 
which  come  under  the  general  heading  of  structured  analysis.  Specific 
techniques  inay  work  best  on  a  particular  type  of  problem.  No  one 
technique  will  fit  all  of  our  work.  Tools  should  be  provided  to 
si^)port  those  techniques  vhich  are  needed  for  our  ^)plications. 

The  output  of  this  phase  will  be  a  good,  well-analyzed,  complete 
description  of  the  problm  to  be  solved.  It  will  be  stored  in  a 
computer  and  each  aspect  of  the  problem  will  be  uniquely  identified. 

In  many  cases  one's  first  association  with  a  project  will  be 
after  the  concept  has  already  been  developed.  If  this  is  the  case, 
one  has  the  choice  of  putting  the  "cc^K^pts  documentation"  in 
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ccmputer-readable  form  or  ignoring  that  and  starting  to  autcmate  at 
the  requirements  specification  phase. 


REQUIREMEN'ES  SPECIFICATION 

R.  Tausworthe  of  JPL  has  defined  requirements  in  the  following 

way: 


A  requirement  is  a  statement  whidi  clearly  and 
accurately  describes  the  essential  technical 
features  of  a  needed  capability,  along  with  a 
set  of  goals,  constraints,  criteria  and  conditions 
to  be  met. 

What  one  must  do  is  to  determine  those  functions  vrtiich  must  be 
carried  out  in  order  to  achieve  a  solution  to  the  problem.  The  output 
of  this  phase  ^ould  tell  v^at  must  be  done  to  solve  the  problem  but 
not  how  it  is  to  be  done.  Which  of  the  functions  will  be  done  by 
hardware,  by  a  computer  and  its  associated  soft3rfare,  or  by  a  human 
being  will  be  specified.  Ihe  resources  necessary  to  complete  the 
project  and  the  high-risk  areas  will  be  identified. 

It  is  important  that  an  effective  solution  be  found  before  any 
implementation  is  attempted.  Iherefore  tools  are  needed  which  will 
not  only  assist  in  the  determination  of  alternate  solutions  but  will 
compare  the  efficacy  of  those  solutions.  The  object  will  be  to 
determine  how  each  prcroosed  solution  will  operate  if  it  is 
implemented.  This  can  be  done  by  modeling,  simulating  at  selected 
levels  of  detail,  studying  the  timing  relationships  of  the  functions 
in  the  proposed  solutions,  by  some  means  of  rapidly  prototyping 
proposed  solutions,  or  some  combination  of  these. 

The  SEE  should  retain  each  of  the  proposed  solutions  and  its 
evaluation  for  future  consideration  of  preposed  modifications.  The 
accepted  solution  should  be  identified  for  easy  access.  Again,  as  for 
all  other  levels  of  system  description,  each  function  should  be 
uniquely  labeled  and  be  traceable  to  hi^er  and  subsequent  lower 
levels  of  documentation.  Each  function  will  have  identified  a  set  of 
tests  which  will  validate  its  inplemention  in  the  ^stem.  The  flow  of 
data  and  control  between  functions  will  be  stored  for  gr^ical 
display  (Functional  Flew  Diagram) . 


7 


NSWC  TR  82-465 


The  following  are  functions  that  should  be  supported  by  the  SEE 
during  this  phase; 

1.  A  cotiputer-processed  language  for  describing  the 
requirements,  abstract  data  structures,  and  test 
requirements 

2.  Tools  for  modeling,  simulation,  and  rapid  prototyping, 
which  will  take  the  specification  of  the  system  to  be 
modelled  from  the  database 


3.  Tools  v^ich  will  assist  in  the  determination  of 
resources  to  carry  out  the  project.  This  will 
consist  of  tools  for  determining  the  amount  of 
thysical  resources,  the  number  of  staff-months, 
and  the  number  of  calendar  months. 


SOFTWARE  SYSTEM  DESIGN 

In  this  phase  the  design,  or  structure,  of  the  software  is 
developed.  The  attempt  will  be  to  break  the  ^stem  down  into  modules 
which  are  small  enough  to  be  understood  easily,  contain  only  functions 
which  are  very  closely  related  and  dependent  on  each  other,  and  do  not 
depend  on  any  other  module  except  for  data.  The  goal  is  to  design  a 
^stem  so  that  any  future  changes  will  influence  only  a  snail  number 
of  modules  and  those  modules  will  be  easily  identifiable. 

There  are  two  designs  to  consider  in  this  phase.  Ihere  is  the 
design  of  the  sequences  of  the  functioral  modules  and  the  design,  or 
layout,  of  the  data. 

The  following  are  the  functions  that  ^ould  be  supported  by  the 
SEE  during  this  phase: 

1.  A  computer-processed  language  for  describing  the  design 
which  provides  for  a  "readable"  listing  of  the  design, 
consistency  checking,  completeness  checking,  axxi 
traceability  of  functions  betweoi  higher-  ard  lower- 
level  documentation 

2.  Tools  for  graphically  displaying  the  hierarchy  eind  the 
flow  of  control  of  the  modules 

3.  Tools  for  gre^ically  displaying  the  flow  of  data 
between  the  modules,  generally  called  a  data  flow 
diagram 
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4.  Tools  for  constructing  and  modifying  the  structure  of 
the  data  for  the  application  programs,  which  will 
prevent  duplicate  identifiers  and  will  show  the 
relationship  between  each  piece  of  data  and  the 
modules. 

5.  Since  the  software  system  will  be  develcjped 
incrementally  the  environment  must  have  the  capability 
to  add  to  existing  designs  and  to  identify  and  store 
alternate  designs  (configuration  rranagement) . 


OODING  AND  CHEX3(0UT 

During  coding,  the  environment  must  not  only  support  the  new 
software  develofxnent  techniques  but  as  much  as  possible  force 
structure  on  the  resultant  code  and  check  for  conformity  to  coding 
stcindards.  The  ^stem  should  encourage  interactive  generation  of  the 
code  as  opposed  to  writing  it  down  to  be  keypunched.  Automatic 
translation  of  the  design  language  into  code  should  be  provided  as 
ext^sively  as  possible.  The  ^stem  should  assist  in  the  correlation 
of  coding  segments  to  hi^er-level  documentation,  Ptonpts  should  be 
given  for  in-line  documentation,  such  as  prologues  (estplanatcxy 
material  at  the  beginning  of  each  module/routine) .  Facilities  for 
on-line  debugging  should  be  provided.  Statistics  on  the  amount  of 
code  generated  and  the  number  of  modules  coded,  debugged,  and  turned 
over  to  the  configuration  management  team  shcxjld  be  maintained  by  the 
system. 

The  SEE  shcxald  provide  the  folicwing  capabilities: 

1.  The  usual  system  routines  needed  to  develop  code, 
such  as  compilers,  linkers,  leaders,  etc. 

2.  Tools  for  interactive  development  of  software; 
full  screen  editors,  syntax  directed  editors,  etc. 

3.  Simulation  of  the  target  machine  if  not  the  same 
as  the  host 

4.  Scarce  language  debugging 

5.  Instrumentation  of  the  code  to  provide  data 
extraction  when  cxx3e  is  executed 

6.  Context  cross  reference,  i.e. ,  to  be  able  to  review 
higher  levels  of  documentation  vhich  relate  to  the 
section  of  cade  being  implemented.  The  system  should 
determine  thrcxigh  its  traceability  features  vhich 
dcxamentaticxi  is  relevant  and  display  it  on  cxxranand. 
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7.  Metrics  vrtiich  indicate  the  size,  cotnplexity<6><7>, 
performanace,  etc.  of  the  modules 

8.  Analysis  tools  such  as  set/use  maps,  cross  reference 
maps,  etc. 

9.  Facilities  for  generating  stubs  for  testing  the  flow  of 
control  prior  to  the  existence  of  all  modules 

10.  Static  analyzers  which  check  for  conformance  to 
standards,  vhich  ^ould  be  both  general  and  project 
specific 

11.  Error  seeding;  the  eibility  to  insert  errors  to  test 
whether  the  program  will  operate  properly  under  error 
conditions 


lESTINS 

If  one  has  a  separate  test  group,  and  this  is  recommended,  the 
computer  progrcms  making  up  the  system  will  be  turned  over  to  this 
group  ty  the  developer  and  the  progrems  must  be  put  together  and 
tested  as  a  system.  If  a  separate  test  group  does  not  exist,  then  it 
is  advisable  to  have  someone  who  acts  as  a  Program  Secretary  who  is 
responsible  for  all  official  versions  of  the  software.  It  should  now 
come  under  official  control  so  that  changes  will  not  be  made  to  it 
without  proper  controls.  The  programs  making  up  the  ^stem  probably 
will  be  tested  one  at  a  time  and  the  tested  programs  then  incorporated 
into  the  ^stem.  Stubs  may  be  generated  for  those  units  not  complete 
and  tests  run  on  the  resultant  systen.  Since  there  may  be  errors  in 
the  units  requiring  than  to  be  turned  back  to  the  programmer  for 
correction,  there  must  be  a  capability  of  keeping  track  of  each 
version  of  the  units.  There  must  adso  be  a  means  of  identifying  vhich 
versions  of  the  units  are  in  each  subset  of  the  software  ^stem 
tested.  Some  of  the  capabilities  identified  under  Coding  and  Checkout 
may  be  used  during  this  ^ase  in  order  to  provide  final  certification. 
The  development  group  may  cdso  want  to  use  some  of  the  capabilities 
identified  for  this  phase  in  order  to  forestall  future  problems. 

The  SEE  must  have  the  following  capabilities  to  support  testing: 

1.  Static  code  analyzers  to  determine  conformance  to 
standards,  etc. 

2.  Thst  scenario  generation,  test  case  generation  if 
technologically  feasible. 


10 


NSWC  TR  82-465 


3.  !Ihe  ability  to  reference  previous  test  data,  make 
changes  to  it,  and  identify  this  as  another  test 
case. 

4.  Autcmatic  comparison  of  the  results  of  runs  and 
r^wrting  of  the  differences, 

5.  Facilities  for  "instrumenting"  the  program  for  data 
and  ev^r  extraction  during  execution.  When 
comnanded,  the  system  should  autonatically 
instrument  the  code  for  use  in  test  coverage 
analysis. 

6.  Test  r^xarting  vrfiich  includes  test  coverage,  tested 
and  untested  reguiremaits,  etc. 


CX}NFIGURATION  MANftSEMENT 

The  problems  of  oonfigurati<Mi  managemait  are  keeping  track  of 
modifications  to  the  baselined  software,  making  sure  that  none  are 
made  without  formal  approval,  knowing  precisely  the  capabilities  of 
each  version  of  the  software  system,  and  knowing  which  sites  (if  more 
than  cMie)  have  which  version  at  any  given  time. 

To  carry  out  this  function,  the  aivirorment  must  have  a  data  base 
managemait  system  (DBMS)  with  the  capability  of  generating  good 
quality  reports.  As  moitioned  in  the  section  on  general  requirements, 
the  environment  should  have  a  fully  integrated  data  base  which 
contains  all  of  the  information  generated  from  the  beginning  of 
concept  development  to  the  death  of  the  program.  The  PRCDECT  DATA 
BASE  will  be  the  foundation  \hich  everything  in  the  aivironment 
will  be  built.  There  will  need  to  be  a  command  language  which  can  be 
used  to  create  a  systan  of  the  software  from  the  version  numbers  of 
the  modules.  There  must  be  convenient  methods  for  keying  track  of 
change  orders,  trouble/failure  reports,  and  their  status. 


PROJECT  HANM31MEMT  GONSIDBRATIONS 

The  project  managers  must  be  able  to  query  all  data  in  the  data 
base  needed  to  manage  the  project.  This  includes  data  needed  to 
determine  project  schedules  and  status,  product  quality,  etc.  The 
data  ^ould  be  presented  in  the  form  of  quality  reports  rather  than 
isolated  data. 
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Ihe  environment  ^ould  also  have  the  following  capabilities: 

1.  Managemeit  planning/  scheduling  and  tracking  tools;  for 
example/  an  autonat^  Work  Breakdown  Structure  tool 

2.  Goierating/  storing/  and  retrieving  management 
information  such  as  progress  tepotts 

3.  Ihe  ability  to  g^ierate  quality  sunnary  reports  frcm 
data  in  any  area  of  the  data  base. 


12 


NSWC  TR  82-465 


REFERQICBS 


<1>  "Soecied  Report  on  Software  and  Services",  DATAMATK^,  Aug  25, 
1981,  p66. 

<2>  DCD  Annual  Report  EY  81,  29  Jan  1981,  p245. 

<3>  F.  L.  Bauer,  "Software  Engineering,"  information  Processing  71 
(1972),  North  Holland  Publishing  Co.,  pp530. 

<4>  Jaisen,  R.  W. ,  C.  C.  Tonies,  Software  Engineering.  Prentice  Hall, 
Inc.,  1979,  p212. 

<5>  "Confxjter  Software  Life  Cycle  Managemait  Guide,"  NAVELEKINST 
5200.23,  1  Mar  1979,  p  xviii. 

<6>  Harrison,  et.  al. , "Applying  Software  Con(>lexity  Metrics  to 
Progran  Maintenance,"  COMPUTER,  Sept  1982. 

<7>  J.  C.  Zolnowski,  D.  B.  Sinmcms;  "Taking  the  Measure  of  Program 
Complexity,"  AFIPS  Conferenoe  Prooeedinag.  Vol.  50,  1981  National 
Computer  Ccxiference,  pp.  329-336,  1981. 


13 


P 


NSWC  TR  82-465 


BIBLIOGRAPHY 


Greenstein,  J.  S.,  R.  C.  and  B.  H,  Willeges,  "Hianan-Ccrputer  Dialogue 
Design:  Hardware  and  Soft^rare,"  1981  Fall  industrial  Engineering 
rnnfprpnce  Proceedings.  Industrial  Engineering  &  Management  Press, 
Norcross,  Ga.  30092 . 

Hausen,  H.,  Mullerburg,  M.,  Riddle,  W.  E.,  Software  Engineering 
Environments:  A  BibliooraiAiv .  S.  Hunke,  Editor,  North  Holland 
Publishing  Co. ,  1981 . 

Munson,  J.  B,  "Software  Maintainability:  A  Practical  Concern  for  Life 
cycle  Costs,"  IEEE  Computer.  Nov  1981. 

Singer,  A.,  H.  Ledgard,  and  J.  F.  Hueras,  "ihe  Annotated  Assistant;  A 
Step  Towards  Human  Engineering,"  IEEE  T:ansacti(Mis  on  Software 
Engineering.  Vol.  SE-7,  No.  4,  July  1981. 

Stuebing,  H.  G.,  A  Modern  Facility  for  Software  Production  and 
Maintaiance.  NADC,  Warminister,  Pa.  18974. 

Willeges,  B.  H.  and  R.  C.  Willeges,  "User  Considerations  in 
Computer-Based  Information  Systems,"  VPl^u.  Report  CSIE-81-2,  Sept 


NSMC  St  82-465 


DISStlBUmOM 


OcBVUter  Sdtnai  Dspartaent 
VPIC8U  BladoSburg,  Vh.  24061 
(Prs.  Umat,  Hartsoitr  Lindiiulst) 

OoBiiiibec  SdMioe  Deftartnent 
D.  oC  Meucyland 

Oall«9e  Bark  ,  Maryland  20742 
(Dr.  V.  BasUl) 

Dept  of  Nath  and  Gafuter  Scimoe 
Janee  Madison  Qhiversity . 

Harrisontxirg,  Va.  22807 

Dept  of  Jelled  Nath  and  Conputer  Sciences 
University  of  Virginia 
Charlott^ville,  Va.  22901 
(Dr.  J.  Ortega) 

university  of  Seattle 
Dept  of  Software  Engineering 
Seattle,  Wadi.  98122 
(Dr.  Ryu  Y.  Lee) 

Dept  of  Nath  and  Conputer  Sciences 
Mary  Washington  College 
Fretericksburg,  Va.  22401 

Defense  Technical  Infonnation  Center  (12) 

Local:  List  C-1 


Dahlgren; 

FS4  P.  Brown 

G12  L,  Batayte 

K04  20  copies 

K105 

K14 

K301 

K33  Blink 
KSl  (2  copies) 

K52  J.  anithr  J.  Dooley 
K53  Buber 
X54  HoOoy 
N20A,  ICOB 

IQl  N.  Masters,  D.  NoOonnBll 
N22  R.  Crowder 
N31  G.  Stout 


M34  J.  lynch 
M51  Harrison 
E431  (6  copies) 


Miite  Oak| 

E346 

K34  (2  copies) 
N20 

R  42  G.  Powell 
022  H.  Cook 
023  J.  Cottrell 
B432  (2  copies) 


(1) 


END 

DATE 

FILMED 

3-83 

DTIC 


